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Using Mobile IP and Network Mobility (NEMO) 


Status of This Memo 


This memo defines an Experimental Protocol for the Internet 
community. It does not specify an Internet standard of any kind. 
Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The IETF Trust (2007). 
IETF Note 


This RFC is not a candidate for any level of Internet Standard. The 
IETF disclaims any knowledge of the fitness of this RFC for any 
purpose and in particular notes that the decision to publish is not 
based on IETF review for such things as security, congestion control, 
or inappropriate interaction with deployed protocols. The RFC Editor 
has chosen to publish this document at its discretion. Readers of 
this document should exercise caution in evaluating its value for 
implementation and deployment. See RFC 3932 for more information. 
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Abstract 


Multihoming technology improves the availability of host and network 
connectivity. Since the behaviors of fixed and mobile networks 
differ, distinct architectures for each have been discussed and 
proposed. This document proposes a common architecture for both 
mobile and fixed networking environments, using mobile IP (RFC 3775) 
and Network Mobility (NEMO; RFC 3963). The proposed architecture 
requires a modification of mobile IP and NEMO so that multiple Care- 
of Addresses (CoAs) can be used. In addition, multiple Home Agents 
(HAs) that are located in different places are required for 
redundancy. 


1. Motivation 


Users of small-scale networks need an easy method to improve network 
availability and to load balance several links. Multihoming 
technology is one of the solutions to improve availability. 
Conventional major multihoming networks use BGP, but it has some 
issues. Therefore, we propose a multihoming architecture using 
mobile IP [1] and NEMO [2] for small-scale fixed networks. 


1.1. General Benefits of Multihoming 
In a multihoming network environment, both users and network managers 
benefit from controlling outgoing traffic, incoming traffic, or both 
of them. Those benefits are described in "Goals and Benefits of 
Multihoming" [3]. The following is a summary of those goals and 
benefits: 
o Ubiquitous Access 
o Redundancy/Fault-—Recovery 
o Load Sharing 
o Load Balancing 
o Bi-casting 
o Preference Settings 
1.2. Problems to be Solved to Accomplish Multihoming 
Several multihoming technologies have been proposed so far. 


Conventional major multihoming networks use BGP, but it has some 
issues, as follows. 
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(1) Increasing route entries in the Internet 


In the multihoming environments, each user’s network needs to 
advertise its address block to all ISPs connected to them. Ifa 
multihomed user connects to only one ISP, the ISP can advertise 
routing information to aggregate them. But some multihomed users 
need to connect with different ISPs to be prepared for ISP 
failure. In this case, ISPs need to advertise routing information 
for multihomed users without aggregation. Therefore, the number 
of routing entries in the Internet is increasing one by one. 


(2) Difficulty of using multiple links efficiently 
It is not easy to control incoming traffic in the case of the 


conventional multihoming architecture using BGP. Therefore, load 
balancing of connected links is difficult. 


.3. Using the Architecture of Mobile IP and NEMO to Solve the Problems 


Basically, mobile IP (MIP) and NEMO have been proposed for mobile 
hosts or mobile networks; however, their architecture and protocol 
can be used for fixed networks and to solve the problems mentioned 
above. The details of the solution are described in the sections 
below. 


Moreover, by using the architecture and the protocol of MIP and the 
NEMO, the cost of network operation will be decreased. For instance, 
in the architecture of MIP and NEMO, renumbering IP addresses when 
office or network equipment is relocated becomes unnecessary, as the 
network address prefix used by a user network in a mobile IP 
environment does not depend on the upstream ISP’s network prefix. 


Multihoming Architecture Using Mobile IP and NEMO 
1. Mobile Network Includes Fixed Network 


By their nature, NEMO and mobile IP must work with multihoming. This 
is because mobile nodes need to use multiple links to improve the 
availability of network connectivity since the wireless link is not 
always stable. Therefore, we propose that multihoming for fixed 
nodes (routers and hosts) uses the framework of NEMO and mobile IP. 


-2. Overview of Multihoming Network Architecture Using Mobile IP 


Figure 1 shows the basic multihoming network architecture. In this 
architecture, a mobile router (MR), which is a border router of the 
multihomed network, sets up several tunnels between the MR and the HA 
by multiple-CoA registration. An HA (or a router to which the HA 
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belongs) advertises the user’s network prefix (Prefix X in Figure 1) 


to ISPs via the routing protocol. If the HA has several multihomed 
networks (Prefix X and Y in Figure 1), they can advertise an 
aggregated network prefix to ISPs. Therefore, the Internet routing 


entries do not increase one by one when the number of multihomed 
users is increased. 


HA1 
| (Advertise aggregated prefix X and Y) 
v 
ISP 
| 
4+------------------------ 4--------------------- + 
| The Internet | 
+-+---------- +-------------------- 4+---------- +-+ 
| | | 
ISP-A ISP-B ISP-A’ ISP-B’ 
| | | | 
| | | | 
+--- MR ---+ +--- MR ---+ 
CoA1 | CoA2 CoA1|CoA2 
| | 
oSa5oe +--------- (Prefix xX) —-------+------— (Prefix Y) 
Multihomed Network X Multihomed Network Y 


Figure 1: Advertisement of aggregated prefixes 


Packets to multihomed users go to the HA, and the HA sends packets to 
the MR using CoAl and CoA2. The HA selects a route in which a CoA is 
used. The route selection algorithm is out for scope of this 
document. This can improve the availability of the user network and 
control traffic going from the ISP to the MR. In the basic 
architecture, HA1 is the single point of failure. In order to 
improve the availability of the user network, multiple HAs are 
needed. This is described in Section 3.2. 
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HA1 
(1) Packets to prefix X | (2) HA forwards the packets 
are sent to HA v to CoAl or CoA2 
+------- +------ + 
| The Internet | 
+-4+---------- +-+ 
(3) Packets are forwarded over 
the MIP tunnel selected by 
| | v the HA1 
ISP-A ISP-B 
+--- MR ---+ v 
CoA1 CoA2 
SARAR +--------- (Prefix X) 


Multihomed Network A 


Figure 2: Packet Forwarding by HA 


3. Requirements for Mobile IP and NEMO 


3.1. Multiple Care-of-Addresses (CoAs) 


Multiple Care-of-Addresses are needed to improve the availability and 
to control incoming and outgoing traffic. The current Mobile IPv6 
and the NEMO Basic Support protocol does not allow registration of 
more than one Care-of Address bound to a home address to the home 
agent. Therefore, [4] proposes to extend MIP6 and NEMO Basic Support 


to allow multiple Care-of Address registrations for the particular 
home address. 


3.2. Multiple Home Agents 


Multiple Home Agents should be geographically distributed across the 
Internet to improve service availability and for the load balancing 
of the HA. When all the networks that have HA advertise the same 
network prefix to their adjacent router/network, the traffic is 
automatically routed to the nearest Home Agent from the viewpoint of 
routing protocol topology. This operation has already been proven to 
work in the area of Web server applications, such as CDN (Contents 
Delivery Network), with the Interior Gateway Protocol (IGP) and 
Exterior Gateway Protocol (EGP). 
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In order to operate multiple HAs, all HAs must have the same 
information such as binding information. This synchronizes the 
databases among the HAs. The HAHA protocol [5] introduces the 
binding synchronization among HAs. This is the same architecture as 
Internal BGP (IBGP). The database is synchronized by full-mesh 
topology. In addition, in order to simplify operation of the HA, the 
database is synchronized using star topology. This is analogous to 
the IBGP route reflector. 


+--- MR ---+ 
CoA1 | CoA2 


fee ey Va E +--------—- 
Multihomed Network 


Figure 3: Architecture with HA Redundancy 


4. Discussion on the Mailing List 
4.1. Why the Proposed Architecture Uses NEMO Protocols 


The multihomed architecture proposed in this document is basically 
the same as the architecture of NEMO. Furthermore, NEMO protocols 
meet the requirements of the proposed architecture in this document, 
which are: 


o The protocol can be used by the MR to send information such as the 
CoA, Home Address (HoA), and Binding Unique Identifier (BID) [4] 
to the HA. 


o The protocol can establish multiple tunnels between the MR and HA. 


o The protocol supports multiple HAs and can synchronize Binding 
Caches among multiple HAs. 


The proposed multihomed architecture uses NEMO protocols as one of 
the applications of NEMO. Needless to say, using the NEMO protocol 
is one of the solutions to accomplish the proposed multihome 
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architecture. Another solution is to propose a new protocol just 
like NEMO. Nevertheless, such a protocol would have functions just 
like those of NEMO. 


4.2. Route Announcement from Geographically Distributed Multiple HAs 


In the proposed architecture, the xSP (Multihomed Service Provider) 
is introduced. The xSP is a conceptual service provider; it doesn’t 
have to be connected to the Internet physically for all practical 
purposes. xSP has one or more aggregatable mobile network prefixes. 
xSP contracts with some ISPs that are physically connected to the 
Internet. The purpose of this contract is to set up some HAs in 
those ISPs’ networks. Those HAs announce the xSP’s aggregated mobile 
network prefixes. This means that HAs work just like border gateway 
routers, and this situation is the same as peering between the ISP 
and xSP. In this case, the origin Autonomous System (AS) announced 
from the HAs is the xSP. 


On the other hand, a multihomed user (a small office user or home 
user) contracts with the xSP to acquire a mobile network prefix from 
the xSP. Each multihomed user has an MR and multiple L3 connectivity 
to the Internet via multiple ISPs, and the MR will establish multiple 
tunnels to the HA. Since the user’s mobile network prefixes are 
aggregated and announced from the HA, the packets to the user’s 
mobile network will be sent to the nearest HA depending on global 


routing information at that time. The HA that received such packets 
will forward them to the user’s network over the established multiple 
tunnels. 


This model of route announcement from multiple HAs is compatible with 
the conventional scalable Internet architecture, and it doesn’t have 
scalability problems. 


5. Implementation and Experimentation 


We have implemented and experimented with the proposed architecture. 
Currently, the system works well not only on our test-bed network, 
but on the Internet. In our experimentation, the MR has two upstream 
organizations (ISPs) and two Care-of Addresses for each organization. 
The MR uses the multiple-CoA option to register the Care-of Addresses 
to the HA. 
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6. Security Considerations 
This document describes requirements of multiple CoAs and HAs for 
redundancy. It is necessary to enhance the protocols of MIP and NEMO 
to solve the requirements. Security considerations of these 
multihoming networks must be considered in a specification of each 
protocol. 
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